Computer networks provide users with an efficient way to share information. It is commonplace, for example, for users to exchange data using collaborative applications such as email or access stored information using other data retrieval applications. One of the more widely used data retrieval applications is referred to as a web browser. Web browsers are typically configured to obtain data from a World Wide Web of interconnected server computers (hereinafter the Web) using a number of standardized data communication protocols. The Web utilizes a client-server architecture made up of multiple client computers executing a Web Browser application that handles connecting to and retrieving information from one or more server applications.
Once the requested information is retrieved, the Web Browser application parses the obtained information and displays aspects of that information to the user. For example, a user may utilize a Web Browser to access a web site that provides information served in the form of Hyper-Text Markup Language (HTML) or in Extended Markup Language (XML). The portions of HTML or XML information that relate to components intended for display are presented to the user via a standard computer display.
The server computer(s) executing at the web site are configured to handle requests for information by executing a suite of applications. One such a web server application handles requests to transfer data (e.g., HTTP requests), whereas Common Gateway Interface (CGI) programs handle access to data stored in a database and can generate HTML documents that are then transmitted to the requesting user. A web server will typically invoke a CGI program when the system receives a request from a client for a particular script. Practical Extension Reporting Language (PERL) scripts and other server side scripting languages are examples of the type of scripts often handled using CGI. Although such scripts can fulfill many system needs, a problem with using CGI scripts is that the scripts become increasingly difficult to create when utilized to access complex data sources or dynamically provide information.
Due in large part to the complexity involved when using the scripting approach, those of ordinary skill in the art often prefer to use Application Servers in lieu of writing complex scripts. Application Servers have far more flexibility and can provide an effective mechanism for accessing databases and generating output documents using a framework that enables developers to add new functionality and handle tasks such as object persistence, session management, and fail-over protection. However, programming an interface to an Application Server is made difficult by the fact that most systems do not have a tightly constrained set of end-users. Since it is increasingly common for businesses to provide business-to-business services involving multiple types of end-users, there is a need for a more flexible approach to building Application Server interfaces.
When developing server applications for electronic data providers, developers face several challenges. The end-users of such systems are generally not pre-defined. Adequately serving the needs of these users requires that the functions implemented to serve the data made available by the system be modified, or new functions added every time the data representation relating to the served data is modified or new data content added. To minimize the cost of adding new functionality or modifying existing ones, an efficient architecture for interfacing with an Application Server or some other data source is needed. It would, for example, be highly desirable if developers could reuse existing program code, minimize the number of locations where the source code must be altered, and prevent alterations in some parts of the code that affect other functions if such effect is not intentional.
A breed of Web application called Web Services, provides a way to resolve some of the problems and accomplish some of the goals stated above. Web Services are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web. Web Services perform functions, which can be anything from simple requests to complicated business processes. Once a Web Service is deployed, other applications (and other Web services) can discover and invoke the deployed service.
Viewed from an application architecture perspective, Web Services provide a method that enables programmatic access to a service which is then implemented by other kinds of software (e.g., middleware). Access is achieved through the use of a listener and an interface for exposing operations supported by a business logic implemented by a traditional middleware platform. The Web Service architecture segments the services it provides into discrete functional components generally destined for use by other server-side software (e.g. CGI programs). The component-based model involves blocks of software program code, which programmers may reuse to extend the system's capabilities. To exchange data between servers associated with different business entities, Application Servers at each of the different business entities communicate using mutually recognizable data communication protocols. An overview of the various protocols and components of the Web Services platform is helpful for purposes of understanding how the architecture is adapted to provide various services.
The basic platform upon which Web Services are based utilizes eXtensible Markup Language (XML), plus Hyper-Text Transport Protocol (HTTP). HTTP is a ubiquitous protocol that acts as the basic mechanism for transporting data across the Web. XML provides a metalanguage for developers to write specialized languages to express complex interactions between clients and services or between components of a service. At the server level the XML data acts as a message that gets converted to a middleware request and the results converted back to XML. Platform support services, such as discovery, transactions, security, authentication, etc. . . . are provided by other services such as SOAP and the Web Services Definition Language (WSDL). Thus, a fully functioning Web Services platform can be thought of as XML+HTTP+SOAP+WSDL+Universal Description, Discovery and Integration Service (UDDI). At higher levels, one might also add technologies such as XAML, XLANG, XKMS, and XFS, although such services are not universally accepted as a mandatory part of the Web Services platform.
Even though some of the protocols have overlapping functionality, each protocol is generally used for a specific purpose. SOAP, for instance, provides remote invocation, UDDI acts as a kind of trader/directory service, WSDL enables the system to express service characteristics, XLANG/XAML provides transaction support for complex web transactions involving multiple web services, and XKMS supports authentication and registration.
SOAP as it is understood by those of ordinary skill in the art is a protocol that defines a uniform way of passing XML-encoded data between computers. SOAP also defines a way to perform Remote Procedure Calls (RPCs) using HTTP as the underlying communication protocol. For example, SOAP provides a framework for describing data using XML to transfer data between computers using existing network infrastructures.
UDDI provides a mechanism for client computers to dynamically locate other web services. This enables business using a UDDI interface, to dynamically connect to services provided by other businesses. A UDDI registry can be thought of as a lookup service for business applications. A UDDI registry has two kinds of clients: businesses that want to offer a service (and its usage interfaces), and clients who want to obtain and use the offered service. UDDI is layered over SOAP and assumes that requests and responses are UDDI objects sent as SOAP messages.
WSDL provides a way for service providers to describe the basic format of Web Service requests over different protocols or encodings. WSDL is used to describe what a Web Service can do, where it resides, and how to invoke it. WSDL typically assumes SOAP/HTTP/MIME are to provide the remote object invocation mechanism. UDDI registries describe numerous aspects of Web Services, including the binding details of the service. Thus, WSDL fits into the subset of a UDDI service description.
WSDL defines services as collections of network endpoints or ports. In WSDL the abstract definition of endpoints and messages is separated from the network deployment or data format binding information. This allows the reuse of abstract definitions of messages (e.g., descriptions of the data being exchanged and collections of operations such as port types). The protocol and data format information relating to a particular port type constitutes a reusable binding. A port is defined by associating a network address with a reusable binding. Each collection of ports is what defines a service. A WSDL document typically defines a network service using the following elements:                Types—a container for data type definitions using some type system (such as XSD).        Message—an abstract, typed definition of the data being communicated.        Operation—an abstract description of an action supported by the service.        Port Type—an abstract set of operations supported by one or more endpoints.        Binding—a concrete protocol and data format specification for a particular port type.        Port—a single endpoint defined as a combination of a binding and a network address.        Service—a collection of related endpoints.So, put simply, WSDL is a template for how services can be described and used by client computers.        
A limitation in using these existing technologies to provide Web Services is that developers must manually write code to access data sources, provide functions called by clients, and retrieve or modify the data in the data source. This is a laborious process. When the data source is modified (e.g. by modifying a database schema), the developer is required to manually modify the source code for any Web Services affected by alterations to the data source. This requires that the developer have an intimate level of knowledge about the source code structure. For the companies that need to maintain such systems, this process is costly and particularly so, when the developer doing the maintenance is different from the one who performed the initial development. Moreover, each time there is a need to modify the database schema, the developer is required to modify many parts of the source code and propagate each of these changes to the clients that interface with the system. When an operation is to be added or modified, all affected services with which the operation (or operation type) is associated may require modification.
To reduce the development and deployment time, there is a need for a method and framework that assists developers and other users with the process of providing network services (e.g. web services) to end-users and facilitates the development and deployment of such network services.